Hi Brad,
I think what might be happening is that the #52xx Vars are only accessed when the Origin Changes.
see the code:
if (origin == settings->origin_index) { /* already using this origin */#ifdef DEBUG_EMC
COMMENT( "interpreter: continuing to use same coordinate system");
#endif
return RS274NGC_OK;
}
So for example if G55 (origin_index=2) is already selected and the x origin 2 offset #5241 is changed and you select G55 again then nothing will happen.
In other words
G55
#5241 = [.4444]
G55 (nothing will change)
#5241 = [.4444]
G54
G55 (the change will take)
I looked at how:
G10L2P2x-2y-8z0
does it and it calls a function called
convert_setup()
You probably need to duplicate all that functionality. You might just consider telling the Interpreter to execute something like "G10L2P2x-2y-8z0". I know it seems silly but then you avoid having your code caring about the internals of the Interpreter.
Regards
TK
| Group: DynoMotion |
Message: 2475 |
From: Brad Murry |
Date: 11/29/2011 |
| Subject: Re: Fixture Offsets |
Ahh.. that makes sense. I am after keeping things loosely coupled as well, though I think I have found a fairly simple solution:: I’ll just set this on initialization of the Interpreter object- Interpreter.p_setup->origin_index = 0; And that should force the first fixture call to pass through the ‘interpreter: continuing to use same coordinate system’ check. I think that should work OK, though I’m certainly open to hearing about it if not. Thanks for looking into it Tom. -Brad Murry From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
Sent: Tuesday, November 29, 2011 4:45 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Re: Fixture Offsets I think what might be happening is that the #52xx Vars are only accessed when the Origin Changes. if (origin == settings->origin_index) { /* already using this origin */ DEBUG_EMC "interpreter: continuing to use same coordinate system"); return RS274NGC_OK; So for example if G55 (origin_index=2) is already selected and the x origin 2 offset #5241 is changed and you select G55 again then nothing will happen. G55
#5241 = [.4444]
G55 (nothing will change) #5241 = [.4444]
G54
G55 (the change will take) does it and it calls a function called You probably need to duplicate all that functionality. You might just consider telling the Interpreter to execute something like "G10L2P2x-2y-8z0". I know it seems silly but then you avoid having your code caring about the internals of the Interpreter. From: bradodarb <bradodarb@...>
To: DynoMotion@yahoogroups.com
Sent: Tuesday, November 29, 2011 1:14 PM
Subject: [DynoMotion] Re: Fixture Offsets Anyone else able to repro this issue?
-Brad Murry
--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
> Hello Tom,
>
>
> As I said before I think we are golden on the Tool Table. I'm still running to some difficulty on setting the work offset parameters programatically.
>
> using KMotionCNC to prove the methods out, I modified like this::
>
> void CKMotionCNCDlg::OnToolSetup()
> {
> TheFrame->GCodeDlg.Interpreter.p_setup->tool_table[12].length = 1.1230000000000000 ;
> TheFrame->GCodeDlg.Interpreter.SetOrigin(1,-100,-100,-100);
> return;
>
> ....rest of the code...
>
> Which should set my G54 xyz to -100(The SetOrigin function I added only does XYZ)
>
> and that function looks like this::
>
> int CGCodeInterpreter::SetOrigin(int index, double x, double y, double z)
> {
>
> int k = (5200 + (index * 20));
>
> p_setup->parameters[k + 1] = x;
> p_setup->parameters[k + 2] = y;
> p_setup->parameters[k + 3] = z;
>
> return 0;
> }
>
>
> The problem comes when I run my gcode and I have a line with G54, the offset does not come into play. It only seems to work if I use your [fixture offset] drop down..
>
> Any thoughts?
>
> Here is the start of my Gcode file:
> %
> O0000
> (PROGRAM NAME - T)
> (DATE=DD-MM-YY - 26-11-11 TIME=HH:MM - 22:15)
> N100G20
> N102G0G17G40G49G80G90
> (UNDEFINED TOOL - 12 DIA. OFF. - 12 LEN. - 12 DIA. - .5)
> N105G54
> N104T12M6
> N106G0G90X.26Y2.4489A0.S1069M3
> N108G43 H12
> N109 Z.25
> N110Z.1
> N112G1Z0.F55.
> N114X4.1792F145.
> N116Y.26
> N118X.26
> N120Y2.4489
> N122X.3296Y2.4479
> N124X.3991Y2.4469
>
> Thank you,
>
> Brad Murry
> |
|
| Group: DynoMotion |
Message: 2478 |
From: Tom Kerekes |
Date: 11/29/2011 |
| Subject: Re: Fixture Offsets |
Hi Brad,
I was thinking the same thing and even tried it and it seemed to work. However I wasn't 100% sure there wouldn't be any side issue. That would mean that the origin_index would be invalid until the next G54,G55,... And also the current offsets would be out of sync with the #Vars. I wasn't sure what you were trying to do. Do you expect for the Operator to be running GCode, halt, edit the fixtures, then continue? If so the change won't have an effect until the next G54,G55,...
Regards
TK
| Group: DynoMotion |
Message: 2480 |
From: Brad Murry |
Date: 11/29/2011 |
| Subject: Re: Fixture Offsets |
Hello Tom, Call me crazy, but I am trying to allow editing of all params and tool table via a configuration page rather than manipulate the .var and .tbl files, similar to how you have provided a convenient page for editing tool data. (Although of course I am leaving that standard EMC functionality in for non-MM applications that do not wish to set things manually. I do realize I could parse through the tried and true file structures and it is of course a trivial task, but I’m a bit of a nutter for strongly typed xml schemas as it all plays nice with my existing frameworks. And no, I would expect the user to set their values prior to any program execution, but the initial value for origin_index is 1 so the G54 values were not taking effect on startup. I believe if you were to provide an ‘Offset Page’ that KmotionCNC would have this same issue. Way back when I always left G54 at 0,0,0 so I had a ‘modal’ machine coordinate system. Then #1 spindle in #1 work zone would use G55, which negates the need for tricking everything anyhow. It would be unreasonable to expect an operator to conform to a certain methodology when using the interpreter this way, so I’m not sure the best approach. Would I be so far off left field to assert that people should never assume G54 on init and should always include it in the start of their program(if they plan to use G54)? And if they do not use it would there any reproductions? -Brad Murry From: DynoMotion@yahoogroups.com [mailto:DynoMotion@yahoogroups.com] On Behalf Of Tom Kerekes
Sent: Tuesday, November 29, 2011 8:08 PM
To: DynoMotion@yahoogroups.com
Subject: Re: [DynoMotion] Re: Fixture Offsets I was thinking the same thing and even tried it and it seemed to work. However I wasn't 100% sure there wouldn't be any side issue. That would mean that the origin_index would be invalid until the next G54,G55,... And also the current offsets would be out of sync with the #Vars. I wasn't sure what you were trying to do. Do you expect for the Operator to be running GCode, halt, edit the fixtures, then continue? If so the change won't have an effect until the next G54,G55,... From: Brad Murry <bradodarb@...>
To: DynoMotion@yahoogroups.com
Sent: Tuesday, November 29, 2011 4:49 PM
Subject: RE: [DynoMotion] Re: Fixture Offsets I am after keeping things loosely coupled as well, though I think I have found a fairly simple solution:: I’ll just set this on initialization of the Interpreter object- Interpreter.p_setup->origin_index = 0; And that should force the first fixture call to pass through the ‘interpreter: continuing to use same coordinate system’ check. I think that should work OK, though I’m certainly open to hearing about it if not. Thanks for looking into it Tom. I think what might be happening is that the #52xx Vars are only accessed when the Origin Changes. if (origin == settings->origin_index) { /* already using this origin */ "interpreter: continuing to use same coordinate system"); So for example if G55 (origin_index=2) is already selected and the x origin 2 offset #5241 is changed and you select G55 again then nothing will happen. G55
#5241 = [.4444]
G55 (nothing will change) #5241 = [.4444]
G54
G55 (the change will take) does it and it calls a function called You probably need to duplicate all that functionality. You might just consider telling the Interpreter to execute something like "G10L2P2x-2y-8z0". I know it seems silly but then you avoid having your code caring about the internals of the Interpreter. Anyone else able to repro this issue?
-Brad Murry
--- In DynoMotion@yahoogroups.com, "bradodarb" <bradodarb@...> wrote:
>
> Hello Tom,
>
>
> As I said before I think we are golden on the Tool Table. I'm still running to some difficulty on setting the work offset parameters programatically.
>
> using KMotionCNC to prove the methods out, I modified like this::
>
> void CKMotionCNCDlg::OnToolSetup()
> {
> TheFrame->GCodeDlg.Interpreter.p_setup->tool_table[12].length = 1.1230000000000000 ;
> TheFrame->GCodeDlg.Interpreter.SetOrigin(1,-100,-100,-100);
> return;
>
> ....rest of the code...
>
> Which should set my G54 xyz to -100(The SetOrigin function I added only does XYZ)
>
> and that function looks like this::
>
> int CGCodeInterpreter::SetOrigin(int index, double x, double y, double z)
> {
>
> int k = (5200 + (index * 20));
>
> p_setup->parameters[k + 1] = x;
> p_setup->parameters[k + 2] = y;
> p_setup->parameters[k + 3] = z;
>
> return 0;
> }
>
>
> The problem comes when I run my gcode and I have a line with G54, the offset does not come into play. It only seems to work if I use your [fixture offset] drop down..
>
> Any thoughts?
>
> Here is the start of my Gcode file:
> %
> O0000
> (PROGRAM NAME - T)
> (DATE=DD-MM-YY - 26-11-11 TIME=HH:MM - 22:15)
> N100G20
> N102G0G17G40G49G80G90
> (UNDEFINED TOOL - 12 DIA. OFF. - 12 LEN. - 12 DIA. - .5)
> N105G54
> N104T12M6
> N106G0G90X.26Y2.4489A0.S1069M3
> N108G43 H12
> N109 Z.25
> N110Z.1
> N112G1Z0.F55.
> N114X4.1792F145.
> N116Y.26
> N118X.26
> N120Y2.4489
> N122X.3296Y2.4479
> N124X.3991Y2.4469
>
> Thank you,
>
> Brad Murry
> |
|
| | | |
